This was previously an informal constant that was copied everywhere. This at least gives it a place to live, and opens the path for button scaling enhancements if needed.

Let me know if my memory of this is incorrect, but I believe your request on the call was to hide the mute button but leave zoom (if present), progress, and instructions.

I moved this to the UI state class, since 1) it was always derived from this anyways, and 2) moving it here means we can pass only the UI state in some cases rather than a full view model.

Another notable change here and throughout: we don't actually need to be passing around State<T> values directly and inspecting their values in most cases. Recomposition will already handle this at the relevant point, and this is a much cleaner API.

This changed to be a nullable parameter rather than a capturing closure for two reasons.

1. The old implementation relied on direct view model access, which we are no longer doing for good reasons.
2. It avoids capturing state in parameters in ways that may be non-obvious. This is cleaner IMO and will still recompose properly off uiState when needed.

Let it be known that I really don't like that we have to do this as a result of moving the button, further reducing the amount of space available for the map. I still think the UI would make more sense if we left the recenter button in the top end grid cell.

1. This is as good a place as any to drop this I think... I think an extension is better than a free function, but there's no place we colud put this that would remove a substantial number of parameters.
2. Note that this can't live in the same file as the declaration in the composeui module, since almost everything about it is MapLibre specific.

I believe that making this a non-optional parameter was a net negative for code quality for not much benefit. It's way too easy to forget to pass it with this many layers, and in fact it was not actually passed down previously. I haven't changed the progressViewSize parameter in this PR, but I also strongly suspect that the same is true of that as well and we should require it at compile itme.

Here's the (IMO fairly elegant) solution I ended up with. We can avoid 1) repeating a lot of code, and 2) leaking out the instruction view size (propagating more boilerplate) than if we moved it up a level (which was my first instinct. I'm pretty happy with this since it's minimal code, with all parameters readily available, and users of the overlay just get it "for free" (fewer composable parameters).